fix: move the improvement log out of the tree behind an accessor - #59

… silent

`.verify-floor.json` has been found BELOW reality four times -- 21 low at the worst, then 8,
then 1, then 2 -- and each was hand-raised after the fact by whoever happened to look. The
stale number was never the defect. `_floor_problems` fired only on `collected < floor`, so a
PR could add tests and never touch the file: silently green, with the floor left permissive
by exactly the number added. #34 and #37 each did precisely that, which is what PR #50 then
had to clean up by hand.

`collected` is now an equality. Too few tests still fails; too many fails as well, printing
the two integers to write and telling you to rebase first.

That also makes the concurrent case self-enforcing, which is the part discipline could not
fix. Once every test-adding branch must edit these same two lines, two concurrent branches
CONFLICT IN GIT -- the second cannot merge without rebasing onto the first and re-measuring
on the actual merge result. This change demonstrated that on itself TWICE inside an hour:
#42 landed underneath it (floor 368 -> 387, ceiling 24 -> 26) and then #59 did (387 -> 391),
and each conflict forced a rebase and a fresh measurement. Under the old one-directional
rule both would have merged green with a floor below reality. Git's own conflict detection
is what enforces "measure on the merge result, not on the branch", the rule the note in that
file had to restate three times with nothing behind it.

`passed` deliberately stays a MINIMUM on passed+skipped. Only collection is
machine-invariant -- a skipped test is still collected, measured the same day at 368 on both
CI and this machine with pass/skip splits of 344/24 against 368/0. Making that one strict
too would fail a machine for honestly naming a missing prerequisite.

Two further fixes in the same change:

* `--update-floor` no longer REPLACES the note. It appends. The note is the only record of
  which prerequisite justifies each ceiling, so overwriting it destroyed the rationale on
  every use -- the file had to carry a warning about its own tool.
* Drift does not block `--update-floor`. The first draft made it a latched gate: a floor
  behind reality became a problem, and the guard was `not problems`, so the one remedy the
  error message named was refused for the existence of the very condition it clears.
  `_blocks_floor_update` lets drift through while real failures still block, sharing
  `DRIFT_PREFIX` so message and predicate cannot diverge.

Selftests cover both directions, skip-invariance, the unset-floor case, the unblock
predicate and note preservation, each with a deliberate-break demonstration. Two of those
tests were themselves defective and the break demo is what caught it: the latched-gate
assert exercised `_blocks_floor_update` in isolation and stayed green when the CALL SITE was
reverted (built-but-not-wired), and the source-text assert written to fix that searched for
a literal that appears in its own line, so it could never fail. The needle is now built from
two fragments and the wiring is asserted at the guard.

Verified on the merge result: 391 passed, 0 failed, 0/26 skipped, 391 collected (floor 391),
84/84 selftests, 43/43 can-fire, 5/5 gates. Ceilings untouched at 26/7/2; floor stays at
main's 391, since this adds selftest assertions rather than pytest tests. black clean at
line-length 100; ruff at main's baseline of 6 pre-existing findings, none added.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…asured

Only `.verify-floor.json` conflicted, the collision this file's own note predicts
and which the branch note had already flagged as likely.

#59 (improvement-log accessor) raised the floor 387 -> 391 on main with four new
tests; this branch raised it 387 -> 388 with one. Resolved as the UNION, not by
taking a side: #59's rationale is retained and the count was RE-MEASURED on the
merge result rather than either number being carried over. 392 collected,
independently confirmed by `pytest --collect-only` before trusting the arithmetic
-- taking a side is what once put the floor 8 tests below reality.

verify.py on the merge result: 392 passed, 0 failed, 0 skipped, 84/84 selftests,
43/43 can-fire, 5/5 gates green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Only `.verify-floor.json` conflicted. Resolved as the UNION per that file's own rule: #59's
rationale (floor 387 -> 391, the improvement-log accessor's four tests) is retained, this branch's
entry is appended, and the count was RE-MEASURED on the merge result -- 394 -- rather than
arithmetic on either side's number. No ceiling moved; the three new tests need no agent CLI, ledger
or installed runtime, so nothing new is skipped.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

… silent

`.verify-floor.json` has been found BELOW reality four times -- 21 low at the worst, then 8,
then 1, then 2 -- and each was hand-raised after the fact by whoever happened to look. The
stale number was never the defect. `_floor_problems` fired only on `collected < floor`, so a
PR could add tests and never touch the file: silently green, with the floor left permissive
by exactly the number added. #34 and #37 each did precisely that, which is what PR #50 then
had to clean up by hand.

`collected` is now an equality. Too few tests still fails; too many fails as well, printing
the two integers to write and telling you to rebase first.

That also makes the concurrent case self-enforcing, which is the part discipline could not
fix. Once every test-adding branch must edit these same two lines, two concurrent branches
CONFLICT IN GIT -- the second cannot merge without rebasing onto the first and re-measuring
on the actual merge result. This change demonstrated that on itself repeatedly: #42 landed
underneath it (floor 368 -> 387, ceiling 24 -> 26, verify.py reformatted), then #59
(387 -> 391), then #61, all in one afternoon. Each conflict forced a rebase and a fresh
measurement; under the old one-directional rule each would have merged green with a floor
below reality. Git's own conflict detection is what enforces "measure on the merge result,
not on the branch", the rule the note in that file had to restate three times with nothing
behind it.

`passed` deliberately stays a MINIMUM on passed+skipped. Only collection is
machine-invariant, measured across machines at 391 collected on both, with pass/skip splits
of 365/26 on CI against 391/0 locally. Making that one strict too would fail a machine for
honestly naming a missing prerequisite.

Two further fixes in the same change:

* `--update-floor` no longer REPLACES the note. It appends. The note is the only record of
  which prerequisite justifies each ceiling, so overwriting it destroyed the rationale on
  every use -- the file had to carry a warning about its own tool.
* Drift does not block `--update-floor`. The first draft made it a latched gate: a floor
  behind reality became a problem, and the guard was `not problems`, so the one remedy the
  error message named was refused for the existence of the very condition it clears.
  `_blocks_floor_update` lets drift through while real failures still block, sharing
  `DRIFT_PREFIX` so message and predicate cannot diverge.

Selftests cover both directions, skip-invariance, the unset-floor case, the unblock
predicate and note preservation, each with a deliberate-break demonstration. Two of those
tests were themselves defective and only the break demo caught it: the latched-gate assert
exercised `_blocks_floor_update` in isolation and stayed green when the CALL SITE was
reverted (built-but-not-wired), and the source-text assert written to fix that searched for
a literal that appears in its own line, so it could never fail. The needle is now built from
two fragments and the wiring is asserted at the guard.

Verified on the merge result: 391 passed, 0 failed, 0/26 skipped, 391 collected (floor 391),
84/84 selftests, 43/43 can-fire, 5/5 gates. Ceilings untouched at 26/7/2; the floor stays at
main's 391, since this adds selftest assertions rather than pytest tests. black clean at
line-length 100; ruff at main's baseline of 6 pre-existing findings, none added.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…is redundant

PR #58's entire change to keepalive_evidence.py is two deletions: the dead `haystack` binding
(decided in the previous commit) and this unused `repo = target.split("#", 1)[0]` in the
selftest loop — `record_run` is passed `target`, never `repo`.

Taking both makes this branch's copy of the file a superset of #58's, and since both are now
identical deletions on both sides, the file merges with zero conflicts in either order —
verified with a 3-way merge against origin/claude/ci-conform-format-lint.

`ruff check --select E4,E7,E9,F` is clean for this file and `black --line-length 100 --check`
leaves it unchanged. #58 is separately CONFLICTING against main (it predates #59 and is a
tree-wide black pass), so it needs a rebase regardless — that is not caused by this branch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

langsmith-fleet-worker-attempt.json is a per-run CI provenance record, not
source. reusable-codex-run.yml (in stranske/Workflows) rewrites it on every
invocation and uploads it as artifact langsmith-fleet-v1-worker-attempt-<pr>.
It became tracked in 2118f57, and because gitignore does not apply to an
already-tracked path, the runner's `git add -A` commit step staged it on every
run: ten commits across PRs #59/#61/#62/#63, one add/add conflict per concurrent
PR, and a silently widened diff on each.

Nothing reads it from the tree. The langsmith-fleet/v1 consumers here
(langsmith_pull.py, langsmith_fetch.py) ingest the NDJSON Actions artifact
`langsmith-fleet.ndjson`; neither names this path. The 30-day artifact upload
already provides the replacement path, so untracking loses no provenance.
stranske/Workflows reached the same verdict for its own copy.

The ignore entry sits outside the synced WORKFLOWS STATUS FILES block, since
that block mirrors a consumer template which does not carry this pattern and
would drop it on the next rewrite.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

langsmith-fleet-worker-attempt.json is a per-run CI provenance record, not
source. reusable-codex-run.yml (in stranske/Workflows) rewrites it on every
invocation and uploads it as artifact langsmith-fleet-v1-worker-attempt-<pr>.
It became tracked in 2118f57, and because gitignore does not apply to an
already-tracked path, the runner's `git add -A` commit step staged it on every
run: ten commits across PRs #59/#61/#62/#63, one add/add conflict per concurrent
PR, and a silently widened diff on each.

Nothing reads it from the tree. The langsmith-fleet/v1 consumers here
(langsmith_pull.py, langsmith_fetch.py) ingest the NDJSON Actions artifact
`langsmith-fleet.ndjson`; neither names this path. The 30-day artifact upload
already provides the replacement path, so untracking loses no provenance.
stranske/Workflows reached the same verdict for its own copy.

The ignore entry sits outside the synced WORKFLOWS STATUS FILES block, since
that block mirrors a consumer template which does not carry this pattern and
would drop it on the next rewrite.

Co-authored-by: t <t@e>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

…rop a claim #3210 falsifies

This branch ended up with two independent explanations of the same rule, because a
concurrent session added `4b5764a` while this branch already carried its own block.
Both were correct; having both in a file whose header is specifically about
gitignore-comment discipline is not.

Kept from the second block, because the first did not have it:
- the artifact was tracked from 2118f57, not merely "on main until today";
- ten commits across PRs #59/#61/#62/#63 rewrote it, one add/add conflict per
  concurrent PR, silently widening unrelated diffs;
- untracking loses no provenance — the producer already uploads the same bytes as
  Actions artifact `langsmith-fleet-v1-worker-attempt-<pr>` with 30-day retention,
  which is the only reason the file is written at all.

Dropped from it, because it is about to become false: "that block mirrors Workflows'
templates/consumer-repo/.gitignore, which does NOT carry this pattern". Workflows
PR #3210 adds exactly these two patterns to that template at Template-Version 6. The
placement above the managed block is still right, but the reason is that a version
bump rewrites the block wholesale — not that the template lacks the pattern.

Also drops that block's bare literal `langsmith-fleet-worker-attempt.json`, which was
already subsumed by the root-anchored `/langsmith-fleet*.json` above it.

Comments only. Verified identical behaviour with `git check-ignore`: the root artifact
and artifacts/langsmith/ stay ignored, docs/contracts/schemas/langsmith-fleet-v1.schema.json
and langsmith_*.py stay committable, and no tracked file is shadowed by any pattern.
427 collected = floor 427; black, ruff and the 11 guard tests unchanged.